I also was thinking about whether a View should be extended to be either a DocumentView or a TerminalView which would allow us to make use of the current splits code for the terminal as well.

I also was thinking about whether a View should be extended to be either a DocumentView or a TerminalView which would allow us to make use of the current splits code for the terminal as well.

all views are splittable: https://github.com/helix-editor/helix/blob/master/docs%2Farchitecture.md, so yeah it makes sense

I also was thinking about whether a View should be extended to be either a DocumentView or a TerminalView which would allow us to make use of the current splits code for the terminal as well.

all views are splittable: https://github.com/helix-editor/helix/blob/master/docs%2Farchitecture.md, so yeah it makes sense

It makes sense to me, but a lot of the View code is inherently tied to Documents, including several macros. It can definitely be rewritten, but that'd make the PR touch a lot more stuff, and the maintainers may not like the direction that would take it. Just didn't want to work on that unless it seems like a good direction 🤷

Everything seems to expect views to be attached to documents, sadly. This makes it very difficult to make use of the existing view logic.

For example, after updating the macros to return options to conditionally give a view and document only if they are of type View::Document, and after fixing about 100 errors to presumably get rust-analyzer to the next step of error reporting. I get this beautiful number of errors.

Maybe the Document structure is what should be updated instead. Looking at that next

I have a genuine question.

What are the benefits of integrating a terminal into Helix?

When you can take advantage of the multiplexer that several terminals offer, or even tmux

I have a genuine question.

What are the benefits of integrating a terminal into Helix?

When you can take advantage of the multiplexer that several terminals offer, or even tmux

That's a fine question. The main benefit for me is windows support. Zellij and tmux don't support windows (except in WSL). Also, having the terminal integrated allows us to do some cool stuff in the future like CTRL+Clicking a file link in an failed compilation to go to the file, line and col that the error references.

I don't think this makes sense or is needed
Clicking? This is helix...?

I don't think this makes sense or is needed Clicking? This is helix...?

There has historically been an interest in this feature, as can be found here.

I also have been interested in this feature for a while, so I decided to do some work to adapt the original PoC.

I'd love to have "clickable" (by keyboard) file links!

I also was thinking about whether a View should be extended to be either a DocumentView or a TerminalView which would allow us to make use of the current splits code for the terminal as well.

what do you think about making View a trait and have the current implementation be DocumentView? Consider also a ViewController that handles events and data to View

but I'm afraid this will touch a lot of code, so it's better as a separate PR because for example, plugins may one day want to support views that aren't attached to a document

I also was thinking about whether a View should be extended to be either a DocumentView or a TerminalView which would allow us to make use of the current splits code for the terminal as well.

what do you think about making View a trait and have the current implementation be DocumentView? Consider also a ViewController that handles events and data to View

but I'm afraid this will touch a lot of code, so it's better as a separate PR because for example, plugins may one day want to support views that aren't attached to a document

View could be a trait or enum, I don't mind either of those. I would like approval from a maintainer that it'd be a good idea before I put in the work.

Also, some ideas on what to do about all the code that expects a view to always have a document would be nice. There are several macros that are used all around helix that would have to be updated. What's the cleanest way to decouple all this?

cc: @the-mikedavis

Also worth considering is a generic of some kind. I think the problem with traits is that if we don't redo the order of things (aka a document has a view, not the other way around), we end up with functions on the view that aren't usable without downcasting.

I can vouch for the Windows support. I have been stuck on Windows due to a multitude of reasons, but an issue I kept facing is a toggleable terminal. Wezterm does handle most of my multiplexing needs, aside from a popup terminal, or a toggleable terminal. I will try to get this running on my fork maybe this week, I have way too much PRs merged there 😅

I can vouch for the Windows support. I have been stuck on Windows due to a multitude of reasons, but an issue I kept facing is a toggleable terminal. Wezterm does handle most of my multiplexing needs, aside from a popup terminal, or a toggleable terminal. I will try to get this running on my fork maybe this week, I have way too much PRs merged there 😅

If you bring it in as-is, just a reminder you'll need to set the SHELL environment variable to the path to PowerShell. I haven't gotten around to handling how it will be configured other than that yet.

Also there are rendering glitches and stuff, but please don't hesitate to provide feedback! :)